@Fourdee
If you find time, would be great if you could play around with various special characters and try to cause a syntax error.

Should not be possible any more. If it survives enough tests, I will remove all the error handling from the function. Makes it ugly 😉.

@MichaIng

Great work 👍

If you find time, would be great if you could play around with various special characters and try to cause a syntax error.

Hopefully i'll get some time tomorrow, will run some tests.

@Fourdee
Sh*t, there is one big issue with automated escaping...

Since all special characters are taken literally, this breaks the use of regex expressions. So, e.g. G_CONFIG_INJECT 'setting1[[:blank:]]*=' ... is not possible any more... and there are many cases where settings allow optional-only spaces and other cases where we want to used regex.

Ah have an idea:

• The regex pattern is usually only required for $1 and optional $4, where usually never a variable is inside. So there we can allow regex, skip escaping, thus require manual escaping if some special char is literally wanted.
• The setting $2 usually contains a variable and we do not need regex there, they would not even be used of course by sed. So there we can do automated escaping.
• It is not 100% consistent: Special chars need to be escaped in $1 and $4 then, but not $2. But for practical use this is the only solution I see that does not require more complicated handling, via e.g. "escaping function" to separately escape variables to pass to G_CONFIG_INJECT first or such...

• Without extended regular expressions, \| within grep is taken as or, instead of literally. This is the same issue as mentioned above with \(1\|2\) which will be interpreted as 1 or 2. So finally it is better to re-enable extended regular expressions, to allow these characters being interpreted literally at all. Otherwise with unlucky e.g. passwords, such escaped characters could be specially treated 🤣.

root@VM-Stretch:/tmp# grep "^[[:blank:]]*setting2 = \|hmmm\|" test
# Added by DietPi:
setting1 = "testing"
setting2 = |hmm|
root@VM-Stretch:/tmp# grep -E "^[[:blank:]]*setting2 = \|hmmm\|" test
root@VM-Stretch:/tmp# grep -E "^[[:blank:]]*setting2 = \|hmm\|" test
setting2 = |hmm|

€: 🈯️ Re-enabled ext regex. More escaping, but no other chance to avoid surprises

• Newline is not supported within the setting. This is actually good, since we cannot predict when it is really wanted and when.
• Solution is new option, to explicitly allow newlines. Simply replace \\n with \n then.

€: 🈯️ Enabled newline support via GCI_NEWLINE (G_CONFIG_INJECT)

• Whiptail handles newline calls differently. It is not possible to escape them there.
• whiptail --msgbox 'line1\\nline2' 10 230 echo, grep, sed, I guess POSIX conform is to read the backslash as escaped, thus literally, thus not expand the newline. But whiptail always does 🤔. However, this is minor...

€: Leave as is, very rare and visual only issue, no workaround possible, due to whiptail internal handling

@MichaIng

Thanks Micha, great work 👍

Merged for testing.